我与 AI 的磨合之路

引言

我采用任何有意义的工具的经验是，我必然会经历三个阶段：（1）低效期（2）适应期，最后（3）改变工作流程甚至生活的发现期。

在大多数情况下，我必须强迫自己度过第一和第二阶段，因为我通常已经有一套自己满意且习惯的工作流程。采用新工具感觉像是额外的工作，我真的不想付出这些努力，但为了成为一个全面发展的技术从业者，我通常还是会去做。

这就是我如何在 AI 工具中找到价值的旅程，以及我接下来要尝试的方向。在充斥着过度戏剧化、炒作观点的海洋中，我希望这篇文章能代表一种更加细腻、审慎的方式来看待 AI，以及我对它的看法是如何随时间变化的。

这篇博客完全是我用自己话手写的。我讨厌必须这么说，但鉴于主题内容，我想明确表达这一点。

第一步：放弃聊天机器人

立即停止尝试通过聊天机器人（如网页版 ChatGPT、Gemini 等）来完成有意义的工作。聊天机器人确实有价值，也是我日常 AI 工作流程的一部分，但它们在编程方面的实用性非常有限，因为你主要是指望它们根据之前的训练得出正确的结果，而纠正它们需要人类（你）反复告诉它们错了。这是低效的。

我认为每个人第一次接触 AI 都是通过聊天界面。我也认为每个人第一次尝试用 AI 编程都是让聊天界面写代码。

第一个"哇哦"时刻： 当我还是一个重度 AI 怀疑论者时，我第一次把 Zed 的命令面板截图粘贴到 Gemini 中，让它用 SwiftUI 复现，结果它做得非常好，我真的惊呆了。今天 Ghostty macOS 版中的命令面板，只是对 Gemini 几秒钟内为我生成的代码做了很轻微的修改。

但当我尝试在其他任务中复现这种效果时，我很失望。在存量项目的场景下，我发现聊天界面经常产生糟糕的结果，我发现自己在界面之间来回复制粘贴代码和命令输出时非常沮丧。这显然比我自己做工作效率低得多。

要找到价值，你必须使用 Agent。 Agent 是行业通用术语，指的是能够在循环中进行对话并调用外部行为的 LLM。Agent 至少必须具备以下能力：读取文件、执行程序和发起 HTTP 请求。

第二步：复现你自己的工作

我旅程的下一阶段是尝试 Claude Code。直接说结论：最初我并没有留下深刻印象。我的会话结果并不好。我觉得必须修改它产出的所有内容，而这个过程比我自己做还要花更多时间。

我没有放弃，而是强迫自己用 Agent 复现所有我手动完成的提交。 我真的把工作做了两遍。我先手动完成工作，然后让 Agent 产出在质量和功能上完全相同的结果（当然，不让它看到我的手动解决方案）。

这个过程极其痛苦，因为它阻碍了简单地把事情做完。但我在非 AI 工具上有足够的经验，知道摩擦是自然的，我无法在穷尽努力之前得出一个坚定、可辩护的结论。

从第一性原理出发的关键发现：

把会话分解成独立的、清晰的、可执行的任务。不要试图在一个超大会话中"画完整只猫头鹰"。
对于模糊的需求，把工作分成独立的规划会话和执行会话。
如果你给 Agent 一种验证其工作的方法，它往往能自己修复错误并防止回归。

更广泛地说，我还发现了 Agent 当时擅长什么、不擅长什么的边界，以及对于它们擅长的任务，如何获得我想要的结果。

所有这些带来了显著的效率提升，以至于我开始自然地使用 Agent，感觉它不比我自己做慢了（但我仍然不觉得它更快，因为我大部分时间都在看护 Agent）。

负空间： 这里效率提升的一部分来自于理解什么时候不应该使用 Agent。把 Agent 用在它很可能失败的事情上显然是巨大的时间浪费，而具备完全避免这种情况的知识会带来时间节省。

在这个阶段，我从 Agent 那里找到了足够的价值，很乐意在工作流程中使用它们，但仍然不觉得有任何净效率提升。

第三步：下班前的 Agent

为了尝试找到一些效率，我接下来开始了一个新模式：把每天的最后30分钟用来启动一个或多个 Agent。 我的假设是，也许如果 Agent 能在我无论如何都无法工作的时间里取得一些积极进展，我就能获得一些效率。

真正有帮助的工作类别：

深度研究会话，我会让 Agent 调研某个领域，比如找到某种语言中所有具有特定许可证类型的库，并为每个库生成多页摘要，包括优缺点、开发活动、社区评价等。
并行的 Agent 尝试我有但没时间开始的各种模糊想法。 我不指望它们产出我会真正发布的东西，但也许能在第二天我开始做这个任务时揭示一些未知的未知。
Issue 和 PR 分类/审查。 Agent 擅长使用 gh（GitHub CLI），所以我手动编写了一个快速脚本，可以并行启动一堆 Agent 来分类 Issue。我不会让 Agent 回复，我只想在第二天得到报告，帮助我找到高价值或低投入的任务。

在大多数情况下，Agent 在不到半小时内就完成了任务。在工作日的后半段，我通常很累，正在退出心流状态，发现自己个人效率很低，所以把精力转移到启动这些 Agent 上，我发现第二天早上能给我一个"热启动"，让我比其他情况下更快地进入工作状态。

第四步：外包那些稳操胜券的任务

到这个时候，我已经非常清楚我的 AI 擅长和不擅长哪些任务。对于某些任务，我非常有信心 AI 会得出基本正确的解决方案。所以我旅程的下一步是：让 Agent 在后台完成所有这些工作，而我同时处理其他任务。

更具体地说，我每天开始时会查看前一晚分类 Agent 的结果，手动筛选出 Agent 几乎肯定能很好解决的 Issue，然后让它们在后台持续运行（一次一个，不是并行）。

与此同时，我在做其他事情。 我没有刷社交媒体（比没有 AI 时刷得多），没有看视频等。我处于自己正常的、AI 之前的深度思考模式，在做我想做或必须做的事情。

这个阶段非常重要：关掉 Agent 的桌面通知。 上下文切换的代价非常高。为了保持高效，我发现作为人类，我的工作是控制何时打断 Agent，而不是反过来。不要让 Agent 通知你。在你工作的自然间隙，切过去看看它，然后继续。

对抗 Anthropic 技能形成论文： "做其他事情"有助于对抗广为宣传的 Anthropic 技能形成论文。你在权衡：不为你委托给 Agent 的任务形成技能，同时继续在你手动进行的任务中自然地形成技能。

到这个时候，我已经坚定地处于"绝对不可能回头"的领域。我感觉更高效了，我现在可以把我的编程和思考集中在我真正喜欢的任务上，同时仍然能充分完成我不喜欢的任务。

第五步：工程化你的约束框架

当 Agent 第一次就产出正确结果，或者最坏情况下产出只需要最少修改的结果时，它们效率最高。实现这一点最可靠的方法是给 Agent 快速、高质量的工具，让它自动知道什么时候错了。

这个概念被称为**"约束框架工程"**——每当你发现 Agent 犯错时，你花时间设计一个解决方案，让 Agent 永远不会再犯同样的错误。

约束框架工程的两种形式：

更好的隐式提示（AGENTS.md）。 对于简单的事情，比如 Agent 反复运行错误的命令或找到错误的 API，更新 AGENTS.md（或等效文件）。
Ghostty 的例子：AGENTS.md
该文件中的每一行都基于一个不好的 Agent 行为，它几乎完全解决了所有这些问题。
实际的、编程的工具。 例如，截图脚本、运行过滤测试等。这通常配合 AGENTS.md 的更改，让 Agent 知道这些工具的存在。

这就是我今天所处的位置。 每当我看到 Agent 做了一件坏事，我都在认真努力防止它再次做那件坏事。

第六步：始终保持一个 Agent 在运行

与第五步同时进行，我也在以始终有一个 Agent 在运行为目标。如果没有 Agent 在运行，我会问自己"现在有什么是 Agent 可以为我做的吗？"

我特别喜欢把这与更慢、更深思熟虑的模型结合起来，比如 Amp 的 deep mode（基本上就是 GPT-5.2-Codex），它可能需要 30 多分钟才能做出小的改动。但另一方面，它确实往往能产出非常好的结果。

我[目前？]没有运行多个 Agent，目前也不太想这样做。 我发现让一个 Agent 运行对我来说是一个很好的平衡，既能进行我觉得愉快的深度手动工作，又能看护我那有点笨但又神秘地富有成效的机器人朋友。

"始终有一个 Agent 在运行"的目标仍然只是一个目标。我估计现在在正常工作日中，我大概有 10% 到 20% 的时间有一个后台 Agent 在运行。但是，我正在积极努力改进这一点。

我不想为了运行 Agent 而运行 Agent。 我只想在有一个我认为对我真正有帮助的任务时才运行它们。这个目标的部分挑战是改进我自己的工作流程和工具，以便我能有源源不断的高质量工作可以委托。

今天

通过这段旅程，我个人已经达到了一个点，我在现代 AI 工具上取得了成功，我相信我正在以一种基于现实的、适当审慎的观点来对待它。我真的不在乎 AI 是否会一直存在，我是一个软件工匠，只是想为了热爱这门技艺而创造东西。

整个领域发展如此迅速，我相信我会很快回顾这篇文章，嘲笑自己的天真。但是，正如人们所说，如果你不能为过去的自己感到尴尬，你可能没有在成长。我只希望我会朝着正确的方向成长！

我在这里没有任何利益关系，当然也有其他原因（除了实用性之外）让人避免使用 AI。我完全尊重每个人在这方面的个人决定。我不是来说服你的！